[MOO-Cows] Re: Execution cost of MOO comments? The Mage Wed, 28 Apr 2004 18:30:09 -0700 On Wednesday, Apr 28, 2004, at 03:11 Canada/Eastern, Neil Fraser wrote: The Mage wrote: As soon as I read of this implementation I acquired my early habit of not commenting my code, not liking the idea of taking such a hit. Was my fear justified. I also know that I can use /* C-style comments */ so long as I preserve the text files my code is stored in, and such comments will not even get stored in the database (which conserves both processor and memory resources). This is what I have been doing as my codebase has burgeoned. But I've still always wondered how much of hit database-stored comments cause... Easy to test. Execute an empty verb: [used 2 ticks, 0.000009 seconds] Add 32 comment lines, each with 26 letters in them: [used 2 ticks, 0.000009 seconds] I'm running version 1.8.0r5-MCeh, other versions may be different. Thanks. Your test is a good idea, but I'm not sure that executing two verbs that are both empty of consequential code is a fair representation of the decisions the compiler makes when encountering comments interspersed with real operations. I think it's possible that in the type of test you mentioned there may be a decision made to dump out of the verb early. Also, I don't think a simple tick-test would take into account the time it takes to load the verb into whatever memory space is used for currently executing code, since the tick counter would probably begin AFTER this step? I'm speculating on that. But your test gives me an idea ... I may write a verb that calls another verb full of calculations repeatedly, one version with tons of comments and one without. And I think one would have to have the loop do enough iterations that you could get a fairly large second counter going ... I'm not sure that your second totals are above the minimum resolution of your machine. At that tiny a duration the difference may not be detectable. In fact, I'm going to do this test right now ... I'm finding I have to up my fg_ticks and fg_seconds and do a million loops, because the measures I am using do not do fractions of a second ... not sure how you made your measurements but I would be curious to find out. Here's the routine I used (object numbers have been changed): @verb #1:frotz none none none @program #1:frotz {t, s1, s2} = { ticks_left(), seconds_left(), time() }; for x in [1..1000000] r = #2:frotz(); endfor notify(player, toliteral({t - ticks_left(), s1 - seconds_left()})); . @verb #2:frotz tnt @program #2:frotz "comment one"; {a, b, c} = {100, 200, 300}; a = b + c; b = c + a; c = a + b; "comment two"; a = b + c; b = c + a; c = a + b; "comment three"; for x in [1..10] "comment four"; a = a + 100; "comment five"; endfor "comment six"; return {a, b, c}; "comment seven"; . I tried the test as is, then with each of comments lengthened by about tenfold (by repeating 'comment X' ten times inside each set of quotes), then I tried it with all seven comments at the top, then with all seven comments at the bottom (after the return), then with all seven comments in the middle (outside the for loop), then with all seven comments inside the for loop. And of course I tried it with no comments at all. In each case I repeated the test at least four or five times ... and when something looked doubtful I went back and verified all the tests and these numbers are totally repeatable, with the occasional 1 second variation that I attribute to differences in the timing of when I pressed return on the initiating the verb (i.e. in the middle of a second versus near the beginning or end of a second). No variations were ever more than a second. The machine in question is (don't laugh) a Pentium 350MHz running FreeBSD 4.7 and it's not being used for anything else. The numbers ticks returned never varied (49000007), but the number of seconds returned changed as follows: THE TEST EXACTLY AS LISTED ABOVE: 36 seconds THE TEST WITH ALL OF THE COMMENTS LENGTHENED TENFOLD: 36 seconds THE TEST WITH ALL OF THE COMMENTS REMOVED: 34 seconds THE TEST WITH ALL OF THE COMMENTS AT THE BEGINNING: 34 seconds THE TEST WITH ALL OF THE COMMENTS AT THE END: 34 seconds THE TEST WITH ALL OF THE COMMENTS IN THE MIDDLE (BEFORE THE LOOP): 34 seconds THE TEST WITH ALL OF THE COMMENTS INSIDE THE LOOP: 37 seconds The clear conclusion is that there is a pure execution cost, albeit very small, to MOO comments, independent of the cost of storing them. But it is interesting th4at clumping all of the comments together, whether at the beginning, the middle, or the end, minimises that cost. This makes me think that what we are seeing is not the cost of evaluating the strings (as I at first suspected), but simply the cost of branching around them. This probably means that comment strings are indeed not compiled as evaluations but as branches to avoid non-operative data. Thus, a bunch of comments in a single clump could be skipped with a single branch, whereas comments interleaved frequently with code increase the cost. The size of comments does not seem to be an issue, further supporting the 'cost of branching' theory. Just to verify the theory, I took the final test (ALL COMMENTS INSIDE THE LOOP), and split the comments into two groups, one just after the 'for' statement, and the second group just before the 'endfor' statement, with the operation 'a = a + 100' dividing them. Sure enough, the execution time went up to 39 seconds. So ... there is a cost, which very minimal but enough so that I would definitely avoid extensive commenting interleaved with code that is called extremely frequently ... especially inside loops: as per above it seems that with a fairly simple verb thoroughly commented the cost could be as much as 10%. It seems that the common habit I have noticed of clumping all of a verb's comments in one block at the beginning developed for a reason... never just discard unexamined the wisdom of the MOO elders, is something I have learned repeatedly. So thanks, Neil, for the kick in the ass to actually do something to find out the answer to this. 87 tM